This PR currently has a working preview of a scalar simulation component. Feel free to play around :-).

Some points

• The case now doesn't own the scalar, and it is just a regular simcomp.
• There is some awkwardness in the simcomp constructor, but this can be addressed.
• Output can be added to fluid's, or redirected to a different file.
• Slight update of scalar_scheme's deferred init, so that scalar_pnpn does not parse json.
• The json passed to the scalar is only the simcomps json, not the whole parameter file.
• Material properties for the scalar are injected into case.material_properties. This is not very pretty right now, as wrong output is given to the log in the beginning. Will be fixed.
• The scalar uses its own solver configuration, separate from fluid. The idea is eventually to allow having the scalar component with the fluid at all (at the point where fluid is also a simcomp).
• Fixes simcomp init order in the simcomp_executor and adds a json util for extracting array items (both will be cherrypicked to separate PRs)
• the scalar_mms example is updated to the new settings.

I guess it is still somewhat an open question if we want to go this way. I like it, but one does need to realize that the burden of getting the order of simcomps is on the user here. For example, the probes simcomp crashed for me because it tried to find the "s" field during init, and it was init before the scalar :-). We have an order parameter, to deal with this, but the crashes one gets are difficult to understand as a user. Perhaps, there can still be some guards implemented, but I don't think we can get all possible combos.

Another question I have is regarding gs and coef. Scalar takes the from fluid, but I would like to separate the two. I guess creating and extra gs and coef is not a very good option? Should these be moved up to case, perhaps? Almost everything relies on coef in general, so if fluid will be non-obligatory, I feel like we need to have coef elsewhere.

Lastly, I am pondering on whether scalar_scheme should deal with json parsing or that should all be done in the simcomp. If so,
we will need to pass more stuff to the constructor. The main barrier is that some stuff has to be passed as json anyway, particularly, the source_terms object, which is then used to init the scalar_source_term component of the scheme. So maybe one just pass the whole json anyway...